By now, almost everyone is familiar with the Internet and the World Wide Web (the Web). The Internet is a collection of interconnected communication networks that span the globe. Information content on the Internet is presented via pages, each page comprising a file that is stored on (or dynamically built by) a computer server that is coupled to the Internet and assigned a Uniform Resource Locator (URL), which is essentially an address on the Internet.
Hypertext transfer protocol (http) is the protocol used for transferring Web pages over the Internet. Servers are computers that form part of the Web and whose general purpose is to provide (or serve) information to other computers coupled to the Web. Those computers that are used to access information via the Web from servers are typically termed client machines or client computers.
Web browsers are computer programs that run on client machines that enable one to access and view Web pages via direct addressing (typing the address of a Web page in an address field of the browser) and/or by hyperlinking, as is well known in the art. Netscape Navigator and Microsoft Explorer are two of the most common Web browsers in use today. In the terminology of this specification (as well as in the pertinent industries), the accessing of a Web page by a client machine is called a “request” or an “http request.”
In a common example, a customer accesses a Web retailer's Web site from a desktop computer using a Web browser. The customer's desktop computer utilizing the Web browser software would be considered a client machine.
The Web browser requests a particular Web page using http in a manner well known to those of skill in the art. Upon receipt of the request for a particular Web page, the server corresponding to the URL of the requested page serves the HTML code for that page to the client machine via the Internet.
Http is a connectionless transfer protocol. This means that each request for a Web page transmitted from a client to a server is completely freestanding and contains no http information that relates that request to any other requests. Thus, http itself has no provision for state information that would allow a server (or a client) to maintain historical information about a series of related http requests (e.g., consecutive requests for pages from a single Web site by a single client).
While the discussion so far has referred to a Web site server in the singular, it actually is common for a high traffic Web site to operate a multiplicity of servers, collectively termed a server farm, to service requests from clients. The term server is frequently used in the relevant industries to refer to different physical computers. However, it also is loosely used in the relevant industries to refer to a software module that is dedicated to a particular server task. Thus, when the term is used in this latter manner, two or more servers can reside on a single computer. In this specification, we will use the term server in the latter, broader sense unless otherwise noted.
The number of ways that a Web site operator can divide computing tasks among multiple physical computers and software modules is virtually limitless. For example, a server farm may have an http server at its front end interfacing to the Internet that processes the transfer aspects of a transaction, such as parsing the requests and dispatching them to an appropriate application server in the farm based on one or more of (1) content specific information in the request, (2) load balancing considerations, and (3) session affinity considerations (all of which are discussed in more detail later in this specification). Then, separate application servers may handle the content-specific processing for the transactions. For instance, in a retail Web site, the application server typically would run at least two applications, namely, a first application that builds and serves Web pages dynamically responsive to specific requests from clients. This application, herein termed the “front-end” or “shopping” application, is what allows a client to navigate through a retail Web site to identify goods for purchase and add them to a virtual shopping cart, as is well known in the art.
When the individual using the client machine wishes to check out, a second application, herein termed the “back-end” or “business” application, takes over and processes the collected data for a purchase. The business application, for example, may perform such tasks as creating an invoice, creating a bill of lading, checking inventory to determine if the ordered item is in stock, checking the individual's credit card information to confirm validity and the availability of sufficient credit for the purchase, determining shipping costs, and taxes and calculating a total cost. If a Web site receives enough traffic, the shopping application(s) and the business application(s) may be handled by different servers.
There might also be a separate database server that stores databases needed to process requests. Such databases may include, for instance, a database of inventory, a database storing the content that is used to dynamically build Web pages, a database for calculating taxes and shipping costs based on the shipping address, etc. In a large volume Web site server system, not only might different tasks be assigned to different servers, but each task (or group of tasks) may have multiple, redundant, servers for performing those tasks. Particularly, any given server can only service so many requests in a given period. If the Web site expects more traffic than a single server can handle, it simply maintains multiple servers that are clones of each other. A collection of clone servers is commonly called a server group.
In many types of communication sessions between a particular client and a particular server system (i.e., Web site), it may be desirable to associate multiple http requests from a single client to a single Web site with each other so as to be able to maintain state information about a “visit” to the Web site by a particular individual. For instance, at retail Web sites, which commonly use dynamically generated shopping cart pages to keep track of items being purchased by a particular client, maintaining state information is a necessity in order to keep track of the various products selected by an individual for purchase so that a shopping cart page correctly reflecting the goods being purchased can be generated. Typically, each instance in which an individual selects another item for purchase will be contained in a different http request. Accordingly, the server farm must have some mechanism for associating the different http requests from a given client with each other in order to build a shopping cart page for that individual when he or she is ready to check out. Countless other examples exist in which it is useful or necessary to associate a series of requests from a single client machine with each other and maintain state data for that series of related requests.
The term “session” generally is used in the Web application development field to refer to a series of requests to a network server system for which the server system maintains state information. Typically, a session would comprise requests from a single client machine to a single server system that are within a certain time period of each other. The concept of sessions is not limited to use on the Internet or to http, but can be applied to any communication network using any protocol.
Accordingly, ways have been developed outside of the http protocol itself for maintaining such state (or session) information. One of the earliest ways developed for doing this was the use of cookies. Cookies are small pieces of data that a server sends to a client machine and that the client's Web browser knows to store in a designated cookie folder or in the browser memory. Thereafter, when that client sends a http request for a Web page to that server, the client's Web browser software sends the cookies associated with that URL to the server. The cookie might contain any particular information that the Web site operator feels the need to have in order to better service its customers. As an example, many Web sites allow individual clients to customize Web pages, such as a daily, electronic, newspaper containing only those articles that meet certain criteria selected by the customer and which criteria are stored as part of a cookie. Persons of skill in these arts will recognize that other mechanisms for storing state data are known. However, the use of cookies is probably the most ubiquitous of the various mechanism in use today.
Java is an object-oriented programming language developed by Sun Microsystems, Inc. expressly for use in the distributed environment of the Internet. It can be used to build small application modules, known as applets, that make it possible for a Web page user to interact with a page. Applets are small programs that can be delivered to a Web browser as part of an HTML page and that can execute at the client side to provide dynamic content and/or allow for interactivity. Web browsers that include a Java Virtual Machine (JVM) can run Java applets. For example, a Java applet can allow a user at a client machine to enter data onto a form.
A Java servlet essentially is a server-side equivalent of an applet. A Java servlet Application Program Interface (API) is a specific method prescribed by a computer operating system or by another application program by which a programmer writing an application program can make requests of the operating system or other application. A Java servlet API provides Web developers with a simple, consistent, mechanism for extending the functionality of a server and for accessing existing business systems, i.e., the application program with which the HTML code interfaces. Java servlets are server and platform independent.
The Javax.servlet.http.HTTPSession object (commonly called HttpSession) is an object of a Java servlet API and is a newer way of maintaining state information at the server side. Javax.servlet.http.HTTPSession is a Java servlet object that uses cookies and builds on the cookie concept (as well as some of the other means of tracking state data) in a layer on top of the http layer. It is built using cookies (and/or other existing state data tracking techniques) and associates http requests with those cookies (and/or the particular data pieces used in other data tracking techniques). For further information concerning HttpSession, Java servlet APIs and the other matters discussed above, reference can be made to the Java Servlet 2.2 (or later) specification.
Since the present invention will be described in this specification in connection with specific embodiments adapted to the Java Servlet 2.2 scheme, a discussion of some pertinent Java Servlet 2.2 terminology and rules is in order. First, in Java Servlet 2.2 (hereinafter Servlet 2.2), a session ID (identification) is a code that defines a set of related requests (typically, but not necessarily, requests from one particular client within a certain period of time of each other). When a server creates a session, it assigns a unique session ID value that is sent back top the client machine under the name jsessionid. Thereafter, the client machine will include the session Id in all requests issued to that server farm. The session ID might be sent in a cookie that forms part of the request. Alternately, it might be appended to the URI of the request in a mechanism known as URL rewriting.
The actual state information is called the “session” in Servlet 2.2. In Servlet 2.2, a session ID may be shared across multiple applications and servers, but not the session (i.e., the actual state information). However, it is possible for applications to share data through other means. One such way is through the use of a database.
Since http is a connectionless protocol, one request in a particular session can be directed to one clone in a server group while the next request in the same session might be directed to another one of the clones in that server group. Accordingly, often a mechanism is provided for allowing different servers in a server group to share session data. Such mechanisms are commonly termed session persistence mechanisms. One common persistence mechanism of enabling such sharing of http session data is the use of a database server for storing session data and that is accessible to the plurality of application servers. Particularly, an application server will store session data in local memory, but may also write a copy of the session data to the session database. When a different server clone services a request in that session, that different server can go to the database and read out the session data for that session.
However, reading session data from the database is undesirable because it is an expensive operation in terms of time and use of system resources. Accordingly, many server systems utilize an affinity scheme that attempts to direct all requests sharing a session ID to the same clone in a server group. In such a scheme, a request having a particular session ID would be directed to a different clone in a server group only in the case of the original server for that session failing.
In a complex, large scale, server farm such as described above, it is often the case that a set of requests having a particular session ID may be handled by a server in a first server group, then a next set of requests sharing the same session ID are handled by a server in a different server group, and then a next set of requests sharing the same session ID must be handled by a server in the first group again. As merely one example, an individual shopping on a large retail Web site may first add several items to a virtual shopping cart, which http requests are handled in the front end application server or server group that is dedicated to the shopping application. The individual may then check out, wherein, in this particular Web site, the check out application processes are handled by a different server or server group. Then, partially through the check out procedure, the individual may decide to add another item to the shopping cart. Accordingly, the client machine issues http requests that return the servicing of the requests back to the first server group.
It is an object of the present invention to provide a method and apparatus for maintaining session affinity across multiple server groups.
It is another object of the present invention to provide a method and apparatus for maintaining session affinity within a server group when requests sharing a session ID switch from a first server group to a second server group and then return to the first server group.